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Definition of IETF Working Group Document States 


Abstract 


The IETF Datatracker tool needs to be enhanced to make it possible 
for Working Group (WG) Chairs to provide IETF participants with more 
information about the status and progression of WG documents than is 
currently possible. 


This document defines new states and status annotation tags that need 
to be added to the Datatracker to enable WG Chairs and their 
Delegates to track the status of Internet-Drafts (I-Ds) that are 
associated with their WGs. This document also describes the meaning 
of all previously implemented I-D states and substate annotation tags 
currently used by IETF Area Directors to indicate the status of I-Ds 
that have been sent to the IESG for evaluation and publication. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6174. 
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Copyright Notice 


Copyright (c) 2011 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 


to 


this document. Code Components extracted from this document must 


include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Les 


Introduction 


The IETF Datatracker is a web-based system for managing information 
about Internet-Drafts (I-Ds) and RFCs, IPR disclosures, liaison 
statements, and several other important aspects of the IETF process 
[IDTRACKER]. 


The Datatracker is currently able to track and report on the status 
of I-Ds that have been submitted to the IESG for evaluation and 
publication. Appendix A of this document describes all of the 
document states and substate annotation tags used by IETF Area 
Directors (ADs) to indicate the status of I-Ds that have been sent to 
the IESG. 


In contrast, the Datatracker has almost no ability to indicate the 
status and progression of I-Ds before they are sent to the IESG. The 
Datatracker can only track the availability status of I-Ds today 
(e.g., "Active", Expired", "Withdrawn", "Replaced by") and in some 
cases indicate which IETF Working Group (WG) an I-D is associated 
with (if any). 


Section 3 of this document contains a summary of the Datatracker’s 
current ability to track and report on the status of I-Ds in the IETF 
document stream. The IETF document stream is defined in Section 
5.1.1 of RFC 4844 [RFC4844]. 


Section 4 of this document defines several new I-D states and I-D 
status annotation tags that need to be added to the Datatracker to 
enable status tracking and reporting for WG I-Ds. 


Conventions Used in This Document 


A "working group I-D" (WG I-D) is an Internet-Draft that has achieved 
consensus for adoption as a work item by a WG (compared to an 
individual submission I-D that has not, or has not yet, achieved 
consensus). 


The terms "WG I-D", "WG document", and "WG draft" are used 
synonymously throughout this document. The same is true for the 
plural case of each term. 


The terms "WG document" and "WG draft" are not intended to apply to 
any other document that may be reviewed, discussed, or produced by an 
IETF working group. Working group meeting materials such as Blue 
Sheets, agendas, jabber logs, scribe’s notes, minutes, and 
presentation slides are not to be considered "WG documents" or "WG 
drafts" in the context of this document. 
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The phrase "WG status of an I-D" is to be interpreted as referring to 
the state that an I-D is in, as defined in Section 4.2 of this 
document. This phrase does not refer to an I-D’s availability status 
(e.g., "Expired", "Active", "Replaced by") as described in Section 
3.1, or to any of the IESG states used by Area Directors to describe 
the status of I-Ds they may be evaluating. 


3. I-D States Already Implemented by the Datatracker 


This section describes capabilities that are currently implemented in 
the Datatracker to track the status of I-Ds in the IETF document 
stream. 


The document availability states described in Section 3.1 are 
applicable to every I-D submitted to the IETF. 


The IESG document states and substate annotation tags described in 
Section 3.2 and Appendix A are only applicable to I-Ds that have been 
submitted to the IESG for evaluation and publication. 


The Datatracker currently has no I-D states or I-D status annotation 
tags to describe the WG status of any I-D. 


3.1. I-D Availability States 


The Datatracker currently maintains availability status information 
for every I-D submitted to the IETF. The I-D availability states are 
as follows: 


- Expired 

- Active 

- Replaces 

- Replaced by 

- Withdrawn by Submitter 
- Withdrawn by IETF 

- RFC 


The first four I-D availability states are explained in the following 
subsections. The other states are self-explanatory. 


Note that the Datatracker describes the status of some I-Ds with the 
phrase "I-D Exists". "I-D Exists" is the state that is manufactured 
by the Datatracker to describe I-Ds for which it has no other status 
information. For example, the tool currently uses "I-D Exists" to 
describe I-Ds that are not expired and that have not been sent to the 
IESG. 


Juskevicius Informational [Page 5] 


RFC 6174 IETF Working Group Document States March 2011 


3.1.1. Expired 


An "Expired" I-D is a document that is more than six months old and 
that has not been updated or replaced by a newer I-D or an RFC. 


Every I-D has a normal lifespan of 185 days. An I-D will expire and 
be deleted from the I-D repository after six months unless it is 
updated or replaced by a newer version. One exception is that an I-D 
undergoing official evaluation by the IESG will not be expired before 
its status is resolved (e.g., the I-D is published as an RFC). IESG 
states that do not relate to a formal request to publish a document 
(e.g., "AD is Watching") do not prevent an I-D from expiring. 
[AUTHGUIDE] 


3.1.2. Active 


An "Active" I-D is a document that is less than six months old and 
has not been updated or replaced by a newer I-D or an RFC. 


The "Active" availability state is applicable to individual I-Ds and 
WG I-Ds. The Datatracker may also use "Active" to describe the 
status of I-Ds under formal evaluation by the IESG and I-Ds in the 
RFC Editor Queue. As a result, the "Active" I-D availability state 
cannot be used to determine if an I-D is actively being developed by 
a WG. [WGDTSPEC] 


3.1.3. Replaces and Replaced By 


The Datatracker uses "Replaces" and "Replaced by" to describe I-Ds 
that have been renamed and subsequently resubmitted to the I-D 
repository for some reason. 


Two common uses of "Replaced by" are as follows: 


- The filename of an individual I-D that is being considered for 
adoption by a WG typically includes the name of its author (e.g., 
‘draft-author-wgname-topic-nn’). If the individual I-D is adopted 
by a WG it will be "Replaced by" a newer draft having a filename 
that includes the string ’ietf-’ (e.g., *draft-ietf-wgname- 
topic-00'); when the newer WG I-D is submitted to the I-D 
repository, it "Replaces" the older individual submission I-D. 


- The Datatracker also uses "Replaced by" to describe the final 
state of an I-D that has been published as an RFC; the I-D was 
"Replaced By" the RFC. 


Note that getting correct "Replaces" and "Replaced by" data into the 
Datatracker currently requires an explicit request by a WG Chair. 
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Without such a request, an individual submission I-D will co-exist 
with the newer WG I-D that replaces it until the individual 
submission I-D eventually expires. 


The Datatracker’s ability to track "Replaces" and "Replaced by" 
information may need to be extended in the future to handle more 
complex cases such as the following: 


- Two or more I-Ds are merged into (i.e., "Replaced by") a single 
I-D; in such cases, the availability status of the (one) new I-D 
should indicate that the draft "Replaces" two or more older and 
previously separate I-Ds; and 


- One I-D is split or divided into two or more new I-Ds; in this 
case the availability status should indicate that one (older) I-D 
was "Replaced by" two or more newer I-Ds. 


3.2. IESG Document States 


In addition to tracking the availability status of every I-D, the 
Datatracker also maintains detailed information about the status and 
progression of I-Ds that have been sent to the IESG for evaluation 
and publication. 


All of the states used by Area Directors to indicate the status of 
I-Ds under evaluation by the IESG are defined in [IESGSTAT] and are 
reproduced for convenience in Appendix A. 


The following subsections describe some common interactions between 
three of the IESG I-D states and normal IETF WG processes. These 
interactions are relevant to several of the new WG I-D states defined 
in Section 4. 


3.2.1. Publication Requested 


When a WG has determined that at least rough consensus exists within 
the WG to advance an I-D, progressing the document is then the 
responsibility of the IESG (unless the IESG returns the I-D to the WG 
for further development). [RFC2418] 


The "Publication Requested" state describes an I-D for which a formal 
request has been sent to the IESG to advance/publish the I-D as an 
RFC, following the procedures specified in Section 7.5 of RFC 2418 
[RFC2418]. This state does not mean that an Area Director has 
reviewed the I-D or that any official action has been taken on the 
I-D other than to note that its publication has been requested. 
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Many WG drafts enter the IESG state machine for the first time via 
the "Publication Requested" state. When an I-D advances through the 
IESG process, its IESG state will change to reflect its progress. 
This said, the WG status of the I-D should not change unless an AD or 
the IESG sends the I-D back to the WG for further development. The 
WG state of an I-D that is being progressed by the IESG is "Submitted 
to IESG for Publication", as defined in Section 4.2.10. 


3.2.2. AD Evaluation 


The "AD Evaluation" state describes an I-D that the responsible Area 
Director has begun to review. The purpose of the AD’s review is to 
verify that the I-D is ready for advancement before an IETF Last Call 
is started or before the document is progressed to the IESG as a 
whole. 


After evaluating an I-D, the responsible AD may decide that the 
document needs to be revised before it can be progressed further. 
The AD may send a working group I-D back to the WG that created it 
for revision. 


When an AD sends an I-D back to a WG for revision, the Datatracker 
will report the IESG state and substate status of the document as "AD 
Evaluation: Revised I-D Needed". If the required revisions are 
extensive, a WG Chair may decide to change the WG state of the I-D 
from "Submitted to IESG for Publication" to another WG state (e.g., 
"Waiting for WG Chair Go-Ahead" or "WG Document") for as long as it 
takes the revised I-D to be developed. The IESG status of the I-D 
will continue to be "AD Evaluation: Revised I-D Needed" until the 
revised I-D becomes available. 


3.2.3. IESG Evaluation 


The "IESG Evaluation" state describes an I-D that is being formally 
evaluated by the entire IESG. Every AD is able to raise any content 
or process issues he/she may have with the document. Issues that are 
blocking approval of the document are called "DISCUSS" comments. A 
"DISCUSS" with serious issues may cause a WG I-D to be returned to 
the WG for revision. 


If the IESG sends an I-D back to a WG for more development, the 
Datatracker will report the IESG state and substate of the I-D as 
"IESG Evaluation: Revised I-D Needed" until a revised version of the 
I-D becomes available. During the time that the I-D is being 
revised, the WG Chair may decide to transition the I-D from the 
"Submitted to IESG for Publication" state into one of the earlier WG 
states (e.g., "Waiting for WG Chair Go-Ahead" or "WG Document"). 
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4. 


4. 


New States and Status Annotation Tags for WG I-Ds 


The status-tracking states described in Section 3 are currently 
implemented in the Datatracker; however, their scope is not broad 
enough to provide good visibility into the WG status of any I-D. 


This section describes new I-D states and I-D status annotation tags 
that need to be added to the Datatracker to make it possible for WG 
Chairs and/or their Delegates (e.g., WG Secretaries) to indicate the 
status and progression of the I-Ds associated with their WGs. 


The WG I-D states defined in this section are a superset of the I-D 
states currently used across all IETF WGs. This is not to suggest or 
imply that all of the WG I-D states must be used by all WG Chairs to 
describe the status and progression of the I-Ds associated with their 
WGs. Chairs may use all or just some of the document states 
illustrated in Figure 1 to describe the WG status of their I-Ds as 
appropriate. 


1. Working Group I-D State Diagram 


Figure 1 is a state machine diagram that illustrates all of the WG 
I-D states defined in Section 4.2 of this document. The names of the 
WG I-D states are capitalized for clarity, and common state 
transitions are indicated via the solid, dashed, and dotted lines. 


The WG I-D state machine illustrated in Figure 1 is intended to be a 
new front-end to the IESG I-D state machine [IESGIDSM] that is 
currently implemented in Datatracker. 


Note that Figure 1 does not show every possible state transition. WG 
Chairs may move an I-D from any WG state to any other WG state as 
appropriate to describe the WG status of the document. The lack of 
an explicit path between two states does not mean that such a state 
transition is precluded. 


The first WG I-D state is "Call for Adoption by WG Issued" and its 
meaning and usage are defined in Section 4.2.1. 


One of several possible last states for a WG I-D is "Submitted to 
IESG for Publication". This state is defined in Section 4.2.10. 
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"I-D EXISTS": 'draft-author-wgname-topic-nn” < - - 


WG I-D State Machine | : 
v (not adopted) 


CALL FOR ADOPTION BY WG ISSUED 
v 
v 
ADOPTED FOR ADOPTED BY WG 
WG INFO ONLY 
(individual I-D "Replaced by" 'draft-ietf-wgname-topic-00') 


vV 


DEAD WG  <-------- > WG DOCUMENT <-------- > PARKED WG 
DOCUMENT ("Replaces" individual I-D) DOCUMENT 
* \ 
/ \ 
/ \ 
v \ 
N 
IN WG ---+ v 
LAST CALL 

r A +--> WG CONSENSUS: 
“ : WAITING FOR 

r v +--> WRITEUP 

r 

3 WAITING FOR | | 

‘ WG CHAIR ---+ | 

, GO-AHEAD v 

. SUBMITTED TO IESG 
("Revised ID Needed") - - < - FOR PUBLICATION 
| 
vV 


IESG Document States 
(see Appendix A) 


Figure 1: WG I-D States and Common State Transitions 
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The Datatracker will be enhanced to automatically generate the 
following two state transitions for all WG drafts: 


- A version-00 I-D that conforms to the 'draft-ietf-wgname-topic-00' 
file naming convention will be moved into the "WG Document" state 
automatically by the Datatracker when the WG Chair approves the 
posting of an I-D; and 


- A WG draft that is moved into the IESG state called "Publication 
Requested" will automatically be moved by the Datatracker into the 
WG state called "Submitted to IESG for Publication". 


All other WG I-D state transitions will require the WG Chairs or 
their Delegates to log in to the Datatracker to manually input the 
appropriate WG state to describe the WG status of an I-D. 


Note that Figure 1 includes an arc from the "Submitted to IESG for 
Publication" state back to the "WG Document" state. This is one 
example of what may happen after an AD or the IESG as a whole sends 
an I-D back to a WG for revision. The WG chair may decide that the 
I-D needs further development and that it needs to return to the "WG 
Document" state for a while. 


4.2. Working Group I-D States 


The WG I-D states defined in this section are a superset of the I-D 
states currently used across all IETF WGs. 


All of the states described herein need to be added to the front-end 
of IESG state machine [IESGIDSM] that has already been implemented in 
the IETF Datatracker. 


WG Chairs and their Delegates will be given the flexibility to use 
whichever of the WG I-D states they feel to be appropriate to 
describe the WG status of the I-Ds associated with their WG. 


It is not suggested or implied that Chairs must use all of the I-D 
states defined herein to describe the status and progression of all 
I-Ds associated with their WGs; Chairs may use all of the WG I-D 
states, or just some of the states. 


Note that an I-D that is not associated with a WG will be in a 'Null” 
state with respect to the WG state machine in Figure 1. 
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4.2.1. Call for Adoption by WG Issued 


The "Call for Adoption by WG Issued" state should be used to indicate 
when an I-D is being considered for adoption by an IETF WG. An I-D 
that is in this state is actively being considered for adoption and 
has not yet achieved consensus, preference, or selection in the WG. 


This state may be used to describe an I-D that someone has asked a WG 
to consider for adoption, if the WG Chair has agreed with the 
request. This state may also be used to identify an I-D that a WG 
Chair asked an author to write specifically for consideration as a 
candidate WG item [WGDTSPEC], and/or an I-D that is listed as a 
"candidate draft’ in the WG’s charter. 


Under normal conditions, it should not be possible for an I-D to be 
in the "Call for Adoption by WG Issued" state in more than one 
working group at the same time. This said, it is not uncommon for 
authors to "shop" their I-Ds to more than one WG at a time, with the 
hope of getting their documents adopted somewhere. 


After this state is implemented in the Datatracker, an I-D that is in 
the "Call for Adoption by WG Issued" state will not be able to be 
"shopped" to any other WG without the consent of the WG Chairs and 
the responsible ADs impacted by the shopping. 


Note that Figure 1 includes an arc leading from this state to outside 
of the WG state machine. This illustrates that some I-Ds that are 
considered do not get adopted as WG drafts. An I-D that is not 
adopted as a WG draft will transition out of the WG state machine and 
revert back to having no stream-specific state; however, the status 
change history log of the I-D will record that the I-D was previously 
in the "Call for Adoption by WG Issued" state. 


4.2.2. Adopted by a WG 


The "Adopted by a WG" state describes an individual submission I-D 
that an IETF WG has agreed to adopt as one of its WG drafts. 


WG Chairs who use this state will be able to clearly indicate when 
their WGs adopt individual submission I-Ds. This will facilitate the 
Datatracker’s ability to correctly capture "Replaces" information for 
WG drafts and correct "Replaced by" information for individual 
submission I-Ds that have been replaced by WG drafts. 


This state is needed because the Datatracker uses the filename of an 
I-D as a key to search its database for status information about the 
I-D, and because the filename of a WG I-D is supposed to be different 
from the filename of an individual submission I-D. 
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The filename of an individual submission I-D will typically be 
formatted as 'draft-author-wgname-topic-nn'. 


The filename of a WG document is supposed to be formatted as 'draft- 
ietf-wgname-topic-nn'. 


An individual I-D that is adopted by a WG may take weeks or months to 
be resubmitted by the author as a new (version-00) WG draft. If the 
"Adopted by a WG" state is not used, the Datatracker has no way to 
determine that an I-D has been adopted until a new version of the I-D 
is submitted to the WG by the author and until the I-D is approved 
for posting by a WG Chair. 


4.2.3. Adopted for WG Info Only 


The "Adopted for WG Info Only" state describes a document that 
contains useful information for the WG that adopted it, but the 
document is not intended to be published as an RFC. The WG will not 
actively develop the contents of the I-D or progress it for 
publication as an RFC. The only purpose of the I-D is to provide 
information for internal use by the WG. 


4.2.4. WG Document 


The "WG Document" state describes an I-D that has been adopted by an 
IETF WG and is being actively developed. 


A WG Chair may transition an I-D into the "WG Document" state at any 
time as long as the I-D is not being considered or developed in any 
other WG. 


Alternatively, WG Chairs may rely upon new functionality to be added 
to the Datatracker to automatically move version-00 drafts into the 
"WG Document" state as described in Section 4.1. 


Under normal conditions, it should not be possible for an I-D to be 
in the "WG Document" state in more than one WG at a time. This said, 
I-Ds may be transferred from one WG to another with the consent of 
the WG Chairs and the responsible ADs. 


4.2.5. Parked WG Document 


A "Parked WG Document" is an I-D that has lost its author or editor, 
is waiting for another document to be written or for a review to be 
completed, or cannot be progressed by the working group for some 
other reason. 
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Some of the annotation tags described in Section 4.3 may be used in 
conjunction with this state to indicate why an I-D has been parked, 
and/or what may need to happen for the I-D to be un-parked. 


Parking a WG draft will not prevent it from expiring; however, this 
state can be used to indicate why the I-D has stopped progressing in 
the WG. 


A "Parked WG Document" that is not expired may be transferred from 
one WG to another with the consent of the WG Chairs and the 
responsible ADs. 


4.2.6. Dead WG Document 


A "Dead WG Document" is an I-D that has been abandoned. Note that 
‘Dead’ is not always a final state for a WG I-D. If consensus is 

subsequently achieved, a "Dead WG Document" may be resurrected. A 
"Dead WG Document" that is not resurrected will eventually expire. 


Note that an I-D that is declared to be "Dead" in one WG and that is 
not expired may be transferred to a non-dead state in another WG with 
the consent of the WG Chairs and the responsible ADs. 


4.2.07. In WG Last Call 


A document "In WG Last Call" is an I-D for which a WG Last Call 
(WGLC) has been issued and is in progress. 


Note that conducting a WGLC is an optional part of the IETF WG 
process, per Section 7.4 of RFC 2418 [RFC2418]. 


If a WG Chair decides to conduct a WGLC on an I-D, the "In WG Last 
Call" state can be used to track the progress of the WGLC. The Chair 
may configure the Datatracker to send a WGLC message to one or more 
mailing lists when the Chair moves the I-D into this state. The WG 
Chair may also be able to select a different set of mailing lists for 
a different document undergoing a WGLC; some documents may deserve 
coordination with other WGs. 


A WG I-D in this state should remain "In WG Last Call" until the WG 
Chair moves it to another state. The WG Chair may configure the 
Datatracker to send an e-mail after a specified period of time to 
remind or 'nudge” the Chair to conclude the WGLC and to determine the 
next state for the document. 
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It is possible for one WGLC to lead into another WGLC for the same 
document. For example, an I-D that completed a WGLC as an 
"Informational" document may need another WGLC if a decision is taken 
to convert the I-D into a Standards Track document. 


4.2.8. Waiting for WG Chair Go-Ahead 


A WG Chair may wish to place an I-D that receives a lot of comments 
during a WGLC into the "Waiting for WG Chair Go-Ahead" state. This 
state describes an I-D that has undergone a WGLC; however, the Chair 
is not yet ready to call consensus on the document. 


If comments from the WGLC need to be responded to, or a revision to 
the I-D is needed, the Chair may place an I-D into this state until 
all of the WGLC comments are adequately addressed and the (possibly 
revised) document is in the I-D repository. 


4.2.9. WG Consensus: Waiting for Writeup 


A document in the "WG Consensus: Waiting for Writeup" state has 
essentially completed its development within the working group, and 
is nearly ready to be sent to the IESG for publication. The last 
thing to be done is the preparation of a protocol writeup by a 
Document Shepherd. The IESG requires that a document shepherd 
writeup be completed before publication of the I-D is requested. The 
IETF document shepherding process and the role of a WG Document 
Shepherd is described in RFC 4858 [RFC4858] 


A WG Chair may call consensus on an I-D without a formal WGLC and 
transition an I-D that was in the "WG Document" state directly into 
this state. 


The name of this state includes the words "Waiting for Writeup" 
because a good document shepherd writeup takes time to prepare. 


4.2.10. Submitted to IESG for Publication 
This state describes a WG document that has been submitted to the 


IESG for publication and that has not been sent back to the working 
group for revision. 


An I-D in this state may be under review by the IESG, it may have 
been approved and be in the RFC Editor’s queue, or it may have been 


published as an RFC. Other possibilities exist too. The document 
may be "Dead" (in the IESG state machine) or in a "Do Not Publish" 
state. 
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4.3. Working Group I-D Status Annotation Tags 


In addition to indicating which state a working group draft is in, 
the Datatracker will allow several substate conditions to be 
identified and tracked. This section defines annotation tags that 
may be used to describe a condition that is affecting a WG I-D (e.g., 
why a document is in the state it is in) or to indicate an action 
needed to progress the document. 


Annotation tags do not change the WG I-D state of WG drafts. 


Each of the annotation tags defined herein may be used to provide 
more information about the status of any WG draft in any state, if it 
makes sense to do so. Each annotation tag may be used by itself, or 
in combination with other tags. 


4.3.1. Awaiting Expert Review/Resolution of Issues Raised 


This tag means that someone (e.g., an author or editor of the WG 
draft, or a WG Chair) has initiated an expert review of the document 
and the review has not yet been completed and/or the resolution of 
issues raised by the review has not yet been completed. Examples of 
expert reviews include cross-area reviews, MIB Doctor reviews, 
security expert reviews, and IANA reviews. 


WG drafts tagged with this annotation should retain the tag until the 
review is complete and possibly until any issues raised in the review 
are addressed. 


4.3.2. Awaiting External Review/Resolution of Issues Raised 


This tag means that someone (e.g., an author or editor of the WG 
draft, or a WG Chair) has initiated some other review of the document 
(e.g., sent it to another Standards Development Organization (SDO) 
for comments via a formal or informal liaison process), and the 
review has not yet been completed and/or the resolution of issues 
raised by the review has not yet been completed. 


WG drafts tagged with this annotation should retain the tag until the 
review is complete and possibly until any issues raised in the review 
are addressed. 

4.3.3. Awaiting Merge with Other Document 
This tag means a decision has been made by someone (e.g., the 


document author, editor, or the WG Chair) to merge the I-D with one 
or more other I-Ds from the same (or another) working group. 
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If the result of the merge is a new I-D having a different title, 
then the old I-D may be declared as being a "Dead WG Document". In 
such a case, the annotation tag should be changed from "Awaiting 
Merge with Other Document" to "Other - see Comment Log" and a 
description of the merge should be entered into the log for 
posterity. 


The Datatracker’s regular 'Replaced by’ information should also be 
set for the old I-Ds to make it easier to find the new merged 
document from the old documents. 


If the result of the merge operation is a revision to the old I-D, 
this annotation tag should be cleared when the revised (merged) I-D 
is submitted to the WG. 


4.3.4. Author or Editor Needed 


This tag means an I-D has lost a primary author or editor, and that 
further work on the I-D cannot continue in an effective or efficient 
manner until a new author or editor is found. 


This tag should be removed after a new primary author or editor is 
found. 


4.3.5. Waiting for Referenced Document 


This tag means that completion of the I-D is on-hold because the 
draft has a dependency on one or more other documents. A typical 
example is where an I-D depends on another IETF document that has not 
yet progressed to a point where it may be referenced; the dependency 
may be on one or more documents in other IETF Working Groups or on 
work in progress documents in other SDOs. 


This tag should be removed after the dependency is cleared. 

4.3.6. Waiting for Referencing Document 
This tag means that completion of the I-D is on-hold because one or 
more other documents are dependent on it, and the WG Chair wants to 
submit all of the documents to the IESG (for publication) 


simultaneously. This tag is the inverse of 4.3.5. 


This tag should be removed after the dependency is cleared. 
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4.3.7. Revised I-D Needed - Issue raised by WGLC 


This annotation may be used to flag an I-D that needs to be revised 
to address issues raised during a Working Group Last Call. This 
annotation may also be used to indicate when the I-D is in the 
process of being revised. 


This tag should be removed after a revised version of the I-D is 
submitted to the WG. 


4.3.8. Revised I-D Needed - Issue raised by AD 


This annotation means the responsible AD raised one or more issues 
with the I-D during "AD Evaluation" and that the AD has sent the 
document back to the working group for revision. This annotation may 
also be used to indicate when the I-D is in the process of being 
revised. 


This tag should be removed after the revised version of the I-D is 
submitted to the WG. 


4.3.9. Revised I-D Needed - Issue raised by IESG 


This annotation means that one or more IESG members had issues with 

the I-D during "IESG Evaluation" and the document has been sent back 
to the working group for revision. This annotation may also be used 
to indicate that the revision to the I-D is in process. 


This tag should be removed after the revised version of the I-D is 
submitted to the WG. 


4.3.10. Doc Shepherd Followup Underway 


This annotation tag may be used to indicate that the Document 
Shepherd for the WG document has begun working on the writeup 
required to submit the document (to the IESG) for publication. 


It is possible that too many I-Ds may arrive in a shepherd’s queue in 
too short a time, and the shepherd cannot create satisfactory 
writeups for all of the documents simultaneously. 


When this annotation tag is set, it means the Document Shepherd has 
started work on the writeup for the I-D. The absence or resetting of 
this annotation tag for an I-D in the "WG Consensus: Waiting for 
Writeup" state indicates the writeup has not yet been started, or has 
been put on-hold for some reason. 
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4. 


7. 


7. 


3.11. Other - see Comment Log 


This annotation tag is a catch-all to indicate that someone (e.g., an 
author or editor of the document, the WG Chair, the Document 
Shepherd) has entered one or more comments about the current status 
of the I-D into the IETF Datatracker. 


Intended Maturity Level of WG Drafts 


The IESG requires a WG I-D to have an "intended maturity level" 
associated with it (e.g., Informational, Proposed Standard, 
Experimental) before the I-D is submitted to the IESG for evaluation 
and publication. This information is also often requested by IETF 
participants. 


I-D maturity levels were first defined in Sections 4 and 5 of RFC 
2026 [RFC2026]. The names of the maturity levels in use today are: 


"Experimental" 
"Informational" 

"Best Current Practice" 
"Proposed Standard" 
"Draft Standard" 
"Standard" 

"Historic" 


+ + RA + F > 


The Datatracker may need to be enhanced to enable WG Chairs to input 
and/or change the intended maturity level of a WG draft before the 
I-D is sent to the IESG. 


Security Considerations 


This document does not propose any new Internet mechanisms and has no 
security implications for the Internet. 
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Appendix A. "IESG Document" States 


This Appendix describes the status information currently stored in 
the IETF Datatracker tool for every I-D submitted to the IESG for 

publication. All of the terms and definitions in Sections A.1 and 
A.2 are copied from [IESGSTAT]. 


It must be noted that I-Ds sent to the IESG for publication (termed 
"TESG Documents" in this Appendix) do not stay with the IESG until 
the day they are published as RFCs. After evaluation, the IESG may 
declare that some I-Ds deserve a "Do Not Publish" label. Other I-Ds 
may become "Dead". Some I-Ds may get sent back to their originators 
(WGs or otherwise), and the rest may go into the RFC Editor queue. 


Note that documents that are not tracked by the IESG (e.g., I-Ds for 
which no request has been made of the IESG) are in a null state with 
respect to the IESG state machine. The IESG state of an I-D that has 
no value assigned to the IESG state variable in the Datatracker’s 
database is ’NULL’. 


A.l. Definition of "IESG Document" States 
A.1.1. Publication Requested 


A formal request has been made to advance/publish the document, 
following the procedures in Section 7.5 of RFC 2418 [RFC2418]; the 
request could be from a WG Chair, or from an individual. Note: the 
Secretariat (iesg-secretary@ietf.org) is typically copied on these 
requests to ensure that the request makes it into the Datatracker. A 
document in this state has not (yet) been reviewed by an Area 
Director nor has any official action been taken yet, other than to 
note that its publication has been requested. 


A.1.2. AD Evaluation 


A specific AD (e.g., the "Area Advisor" for the WG) has begun their 
review of the document to verify that it is ready for advancement. 
The shepherding AD is responsible for doing any necessary review 
before starting an IETF Last Call or sending the document directly to 
the IESG as a whole. 


A.1.3. Expert Review 
An AD sometimes asks for an external review by an outside party as 
part of evaluating whether a document is ready for advancement. 


MIBs, for example, are reviewed by "MIB doctors". Other types of 
reviews may also be requested (e.g., security, operations impacts, 
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etc.) Documents stay in this state until the review is complete and 
possibly until the issues raised in the review are addressed. 


Specific details on the nature of the review may be found in the 
"note" field associated with this state (i.e., within the 
Datatracker). 


A.1.4. Last Call Requested 


The AD has requested that the Secretariat start an IETF Last Call, 
but the actual Last Call message has not been sent yet. 


Aide In Last Call 


The document is currently waiting for IETF Last Call to complete. 
Last Calls for WG documents typically last 2 weeks, and those for 
individual submissions last 4 weeks. 


A.1.6. Waiting for Writeup 


Before a standards-track or BCP document is formally considered by 
the entire IESG, the AD must write up a protocol action. The 
protocol action is included in the approval message that the 
Secretariat sends out when the document is approved for publication 
as an RFC. 


A.1.7. Waiting for AD Go-Ahead 


As a result of the IETF Last Call, comments may need to be responded 
to and a revision of the I-D may be needed as well. The AD is 
responsible for verifying that all Last Call comments have been 
adequately addressed and that the (possibly revised) document is 
ready for consideration by the IESG as a whole. 


A.1.8. IESG Evaluation 


The document is now (finally!) being formally reviewed by the entire 
IESG. Documents are discussed in email or during a bi-weekly IESG 
telechat. In this phase, each AD reviews the document and airs any 
content or process issues they may have. Unresolvable issues are 
documented as "DISCUSS" comments that can be forwarded to the 
authors/WG. See the description of IESG substates in Section A.2 for 
additional details about the current state of the IESG discussion. 
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A.1.9. IESG Evaluation - Defer 


During a telechat, one or more ADs requested an additional two weeks 
to review the document. A defer is designed to be an exception 
mechanism, and can only be invoked once, the first time the document 
comes up for discussion during a telechat. 


A.1.10. Approved - announcement to be sent 


The IESG has approved the document for publication, but the 
Secretariat has not (yet) sent an official approval message. 


A.1.11. Approved - announcement sent 


The IESG has approved the document for publication, and the 
Secretariat has sent out the official approval message to the RFC 
editor. 


A.1.12. RFC Ed Queue 


The document is in the RFC editor Queue (as confirmed by 
http://www.rfc-editor.org/queue2.htm1) 


A.1.13. RFC Published 
The I-D has been published as an RFC. 
A.1.14. DNP - waiting for AD note 


Do Not Publish (DNP): The IESG recommends against publishing the 
document, but the writeup explaining its reasoning has not yet been 
produced. DNPs apply primarily to individual submissions received 
through the RFC Editor. See the "note" field for more details on who 
has the action item. 


Rood los DNP - announcement to be sent 


The IESG recommends against publishing the document. The writeup 
explaining the IESG’s reasoning has been produced, but the 
Secretariat has not yet sent out the official "Do Not Publish" 
recommendation message. 


A.1.16. AD is watching 
An AD is aware of the document and has chosen to place the document 
in a separate state in order to monitor it (for whatever reason). 


Documents in this state are not actively tracked by the IESG in the 
sense that no formal request has been made to publish or advance the 
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document. The AD has chosen to put the I-D into this state, to make 
it easier to keep track of (for his or her own reasons). 


A.1.17. Dead 


The document is "Dead" and is no longer being tracked (e.g., it has 
been replaced by another document having a different name, it has 
been withdrawn, etc.) 


A.2. IESG Document Substates 


Note that the annotation tags described in this section were defined 
circa 2002. If these conditions were modelled today, they would most 
likely be modelled as annotation tags rather than as substates. 


A.2.1. Point Raised - writeup needed 


IESG discussions on the document have raised some issues that need to 
be brought to the attention of the authors/WG, but those issues have 
not been written down yet. (It is common for discussions during a 
telechat to result in such situations. An AD may raise a possible 
issue during a telechat and only decide as a result of that 
discussion whether the issue is worth formally writing up and 
bringing to the attention of the authors/WG) . 


A document stays in the "Point Raised - writeup needed" substate 
until *ALL* IESG blocking comments that have been raised have been 
documented. 


A.2.2. AD Followup 


"AD Followup" is a generic substate indicating that the shepherding 
AD has the action to determine the appropriate next steps. In 
particular, the appropriate steps (and the corresponding next state 
or substate) depend entirely on the nature of the issues that were 
raised and can only be decided with active involvement of the 
shepherding AD. 


Examples include: 


- If another AD raises an issue, the shepherding AD may first 
iterate with the other AD to get a better understanding of the 
exact issue. Or, the shepherding AD may attempt to argue that the 
issue is not serious enough it to bring to the attention of the 
authors/WG. 
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- If a documented issue is forwarded to a WG, some further iteration 
may be needed before it can be determined whether a new revision 
is needed or whether the WG response to an issue clarifies the 
issue sufficiently. 


- When a new revision appears, the shepherding AD will first look at 
the changes to determine whether they believe all outstanding 
issues have been raised satisfactorily, prior to asking the ADs 
who raised the original issues to verify the changes. 


A.2.3. External Party 


The document is awaiting review or input from an external party 
(i.e., someone other than the shepherding AD, the authors, or the 
WG). See the "note" field for more details on who has the action. 


A.2.4. Revised ID Needed 


An updated I-D is needed to address the issues that have been raised. 
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